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ABSTRACT 

Android applications may leak privacy data carelessly or 
maliciously. In this work we perform inter-component data- 
flow analysis to detect privacy leaks between components 
of Android applications. Unlike all current approaches, our 
tool, called IccTA, propagates the context between the com- 
ponents, which improves the precision of the analysis. fccTA 
outperforms all other available tools by reaching a precision 
of 95.0% and a recall of 82.6% on DroidBench. Our ap- 
proach detects 147 inter-component based privacy leaks in 
14 applications in a set of 3000 real-world applications with 
a precision of 88.4%. With the help of ApkCombiner, our 
approach is able to detect inter-app based privacy leaks. 

1. INTRODUCTION 

With the growing popularity of Android, thousands of ap- 
plications (also called apps) emerge every day on the official 
Android market (Google Play) as well as on some alterna- 
tive markets. As of May 2013, 48 billion apps have been 
installed from the Google Play store, and as of September 
3, 2013, 1 billion Android devices have been activated 0. 
Researchers have shown that Android apps frequently send 
the user's private data outside the device without the user's 
prior consent [25]. Those applications are said to leak pri- 
vate data. Android applications are made of different com- 
ponents; most of the privacy leaks are simple and operate 
within a single component. More recently, cross-component 
and also cross-app privacy leaks have been reported [26] . 
Analyzing components separately is not enough to detect 
such leaks. Therefore, it is necessary to perform an inter- 
component analysis of applications. Android app analysts 
could leverage such a tool to identify malicious apps that 
leak private data. For the tool to be useful, it has to be 
highly precise and minimize the false positive rate when re- 
porting applications leaking private data. 

Privacy leaks. In this paper, we use a static taint analy- 
sis technique to find privacy leaks, i.e., paths from sensitive 
data, called sources, to statements sending the data out- 



side the application or device, called sinks. A path may 
be within a single component or cross multiple components 
and/or applications. 

State-of-the-art approaches using static analysis to detect 
privacy leaks on Android apps mainly focus on detecting 
intra-component sensitive data leaks. CHEX 18 , for exam- 
ple, uses static analysis to detect component hijacking vul- 
nerabilities by tracking taints between sensitive sources and 
sinks. DroidChecker [9] uses inter-procedural Control-Flow 
Graph (CFG) searching and static taint checking to detect 
exploitable data paths in an Android application. Flow- 
Droid [3] a l so performs taint analysis within single com- 
ponents of Android applications but with a better preci- 
sion. In this paper, we not only focus on intra-component 
leaks, but we also consider Inter-Component Communica- 
tion (ICC) based privacy leaks, including Inter-Application 
Communication (IAC) leaks. 

Other approaches use dynamic tracking to find privacy 
leaks. For instance, TaintDroid [12] leverages Android's vir- 
tualized execution environment to monitor Android apps at 
runtime in which it tracks how application leaks private in- 
formation. CopperDroid 20 dynamically observes interac- 
tions between the Android components and the underlying 
Linux system to reconstruct higher-level behavior. 

A dynamic approach must send input data to the app 
at runtime to trigger code execution. The input data may 
be incomplete and thus not execute all parts of the code. 
Furthermore, some code may only be executed if precise 
conditions are met at runtime such as a data. In this paper, 
we focus on static analysis to avoid these drawbacks. The 
counterpart of static analysis is that it may yield an over- 
approximation since it analyzes all code even the one that 
could never be executed. 

Static taint analysis for Android is difficult. Despite 
the fact that Android applications are mainly programmed 
in Java, off-the-shelf static taint analysis tools for Java do 
not work on Android applications. The tools need to be 
adapted mainly for three reasons. The first reason is that, as 
already mentioned, Android applications are made of com- 
ponents. Communications between components involve two 
main artifacts: Intent Filter and Intent. An Intent Filter is 
attached to a component and "filters" Intents that can reach 
the component. An Intent is used to start a new component 
by first dynamically creating an Intent instance, and then 
by calling a specific method (e.g. start Activity, startService) 
with the intent previously created as parameter. The intent 
is used either explicitly by specifying the new component to 



call, or implicitly by for instance only specifying the actiorQ 
to perform. The launch of a component is performed by the 
Android system which "resolves" the matching between In- 
tent and Intent Filter at runtime. This dynamic resolution 
done by the Android system induces a discontinuity in the 
control-flow of Android applications. This specificity makes 
static taint analysis challenging by requiring pre-processing 
of the code to resolve links between components. 

The second reason is related to the user-centric nature 
of Android applications, in which a user can interact a lot 
through the touch screen. The management of user inputs 
is mainly done by handling specific callback methods such 
as the onClick method which is called when the user clicks 
on a button. Static analysis requires a precise model that 
stimulates users' behavior. 

The third and last reason is related to the lifecycle man- 
agement of the components. There is no main method as 
in a traditional java program. Instead, the Android system 
switches between states of a component's lifecycle by calling 
callback methods such as onStart, onResume or onCreate. 
However, these lifecycle methods are not directly connected 
in the code. Modeling the Android system allows to connect 
callback methods to the rest of the code. 

Our Proposal. The above challenges will unavoidably 
cause some discontinuities in the control-flow graph. To 
overcome these issues, we present an Inter-component com- 
munication Taint Analysis tool named IccTAQ. IccTA allows 
a sound and precise detection of ICC and IAC links. This 
approach is generic and can be used for any data-flow analy- 
sis. In this paper we focus on using IccTA to detect privacy 
leaks. 

IccTA is based on three software artifacts: Epicc-IccTA, 
FlowDroid-IccTA and ApkCombiner. 

Epicc-IccTA extends Epicc |19j which computes ICC links 
between Android components. Epicc-IccTA leverages Epicc 
to incrementally store the computed ICC links to a database 
for conveniently analyzing a large set of apps. FlowDroid- 
IccTA extends FlowDroid 4 . FlowDroid only finds privacy 
leaks within single components of Android applications but 
not between components. 

FlowDroid-IccTA uses ICC links computed by Epicc to 
improve FlowDroid. Based on these computed links, Flow- 
Droid-IccTA modifies Android applications' code to directly 
connect components to enable data-flow analysis between 
components. By doing this, we build a complete control- 
flow graph of the whole Android application. This allows 
propagating the context between Android components and 
yielding a highly precise data-flow analysis. To the best 
of our knowledge, this is the first approach that precisely 
connects components for data-flow analysis. 

Finally, ApkCombiner helps analyzing multiple Android 
applications by combining multiple apps into one when there 
exist data flows between these apps. This results in having a 
complete control-flow graph of the combined apps. This al- 
lows to propagate the context not only between components 
of a single app but also between components of different 
apps. 

To verify our approach, we developed 26 apps containing 
ICC based privacy leaks. We have added these applications 
to DroidBench [2], an open test suite for evaluating the ef- 

1 Such as android, intent . action. VIEW or .CALL or .EDIT 

2 Our experimental results and IccTA itself are available at 
https://sites.google.com/site/icctawebpage. 



Table 1: The top 8 used ICC methods f 



ICC Method 


Counts(#.) 


TT 1 S / , , \ 

Used Apps(#.) 


startActivity 

start Activity ForResult 

query 


55802 (61.44%) 
11095 (12.21%) 
6606 (7.27%) 


2765 (92.2%) 
1980 (66.0%) 
1601 (53.4%) 


start Service 
sendBroadcast 


3942 (4.34%) 
3472 (3.82%) 


1077 (35.9%) 
790 (26.3%) 


insert 


2100 (2.31%) 


615 (20.5%) 


bindService 


1515 (1.67%) 


644 (21.5%) 


delete 


1238 (1.36%) 


350 (11.7%) 


Other ICC Methods 


5058 (5.57%) 




Total 


90828 (100%) 





T Methods with higher counts are selected when overload 
methods exist 



fectiveness and accuracy of taint analysis tools specifically 
for Android apps. The 26 apps cover the top 8 used ICC 
methods illustrated in Table [1] 

Contributions. To summarize, we present the following 
original contributions in this paper: 

• A novel methodology to resolve the ICC problem by 
directly connecting the discontinuities of Android apps 
at the code level. 

• IccTA, a tool for inter-component data-flow analysis. 

• An improved version of DroidBench with 26 new apps 
to evaluate tools detecting ICC based privacy leaks. 

• An empirical study to evaluate IccTA over an aug- 
mented version of the DroidBench test suite (available 
onlin«0) and 3000 real-world Android applications. 

2. BACKGROUND 

2.1 Android ICC Methods 

An Android application is made of basic units, called com- 
ponents, described in a special file, called Manifest, stored 
in the application. There are four types of components: a) 
Activities that represent the user interface and are the visi- 
ble part of Android applications; b) Services which execute 
tasks in background; c) Broadcast Receivers that receive 
messages from other components or the system, such as in- 
coming calls or text messages; and d) Content Providers 
which act as the standard interface to share structured data 
between applications. 

Some specific Android system methods are used to trig- 
ger inter-component communication. We call them Inter- 
Component Communication (ICC) methods. Those meth- 
ods take as parameter a special kind of object, called In- 
tent, which specifies the target component (s). We perform 
a short study to compute the usage rate of ICC methods. 
We analyzed 3000 Android applications randomly selected 
from Google Play and other third party markets. Table [T] 
shows the top 8 most used ICC methods. The third col- 
umn represents the number of apps using at least once the 
corresponding ICC method. The most used ICC method is 
startActivity, used to launch a new Activity component, 
which accounts for 59.2% of the total detected ICC methods. 

All ICC method^ take at least one Intent in their pa- 
rameters to specify the target component(s). There are two 

3 github.com/secure-software-engineering/DroidBench 
4 Except Content Provider related methods such as query 
or insert 
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Figure 1: Explicit and Implicit ICC between Components 
of Android Applications. 



ways to specify ICC method's target components. The first 
one is by explicitly specifying them by setting the name of 
the target components through an Intent. The second one 
is by implicitly specifying them by setting the action, cate- 
gory and data fields of an Intent. In order to receive implicit 
Intents, target components need to specify an Intent Filter 
in their application's manifest file. Note that Intents can 
transfer data between components. 

Again, we performed a short study on the 3000 apps to 
compute the ratio between explicit and implicit Intents for 
the startActivity ICC method. Among the 55,802 star- 
t Activity method calls, 27978 use explicit intents and 27824 
use implicit Intents. 

Figure [T] represents three Android apps made of Activity 
components. There is an explicit ICC from Activityi to 
Activity2 in Application 1. There are two implicit ICCs 
from Activity2 to Activitys in Application 1 and from 
Activity2 to Activity4 between Application 1 and Ap- 
plication 2. Note that the target components of implicit 
ICC, Activity3 and Activity^, have an Intent Filter with 
the same action and category value as the Intent used in 
Activity2. Each time there is an ICC, there may be a flow 
of data between components and potentially a privacy leak. 

2.2 FlowDroid 

FlowDroid 4 is a context-, flow-, field-, object-sensitive 
and lifecycle-aware static taint analysis tool for Android ap- 
plications. FlowDroid is based on Soot [16] and Heros [8]. 
The context-, flow-, field-, object-sensitives of FlowDroid are 
guaranteed by the precise call-graph of Soot and the IFD- 
S/IDE [211 123] based data-flow analysis of Heros. A special 
main method, which considers all combinations of lifecycles, 
callbacks and entry points of Android components is gener- 
ated to model data flows within the application. The sources 
and sinks used by FlowDroid are provided by SuSi [3], also 
an open sourced tool used to fully automatically classify and 
categorize Android sources and sinks. FlowDroid achieves 
93% recall and 86% precision when detecting data leaks on 
DroidBench. FlowDroid has been mainly used on single 
component. However, with slight modifications, FlowDroid 
could also be used when multiple components are involved, 
i.e., for ICC analyses. Indeed, it's possible to use FlowDroid 
to compute paths for all individual components and then 
combines all those paths together, whatever there is a real 



link or not between these components. A major drawback 
is that this naive approach yields many false positives. 

2.3 Epicc 

Epicc [19] is a tool, also based on Soot and Heros, to iden- 
tify ICC links. In other words it finds links from ICC meth- 
ods to their target components. Epicc reduces the discovery 
of ICC in Android to an instance of the Interprocedural Dis- 
tributive Environment (IDE) problem |23| . It uses data flow 
analysis to compute Intent values at every ICC method call 
statements. Experiments show that Epicc identifies 93% of 
all ICC links and finds ICC vulnerabilities with far fewer 
false positives than the next best tool. 

3. MOTIVATING EXAMPLE 

This section motivates our approach and illustrates the 
problem we solve through a concrete example. This example 
is detailed in Listing[T] which presents code of Application 
1 introduced in Figured] The app has three Activity compo- 
nents represented by Activityi, Activity2 and Activity3 
classes. It also features ButtonOnClickListener a listener 
class used to handle button click events. Activityi regis- 
ters a button listener for the to2 button (lines 6-11) and 
Activity2 registers one for the to3 button (line 15). 



//TelephonyManager telMnger ; (default) 
//SmsManager sms; (default) 
class Activityi extends Activity { 
void onCreate (Bundle state) { 
Button to2 = (Button) f indVi e wBy Id ( t o2a) ; 
to2 . setOnClickListenerfnew OnClickListenerO { 
String id = t e lMnger . getDeviceldO ; 
Intent i = new 

Intent (Activityi. this , Activity 2 . class) ; 
i .putExtra ("sensitive" , id); 
Activityi. this . startActivity(i) ; 
);}} 

ss Activity2 extends Activity { 
id onCreate (Bundle state) { 
utton to3 = (Button) findViewById(to3a); 
o3. setQnClickListener(new 

ButtonQnClickListener(this)) ; 
ntent i = getlntentO ; 

tring s = i.getStringExtra(" sensitive"); 
ms . sendTextMessage( number , null , s , null , null ) ; 

id onActivityResult(int , int , Intent ){ 

/log all the Extras of Intent 

s Activity3 extends Activity { 
id onCreate (Bundle state) { 
ntent i = getlntentO ; 

tring s = i.getStringExtra(" sensitive"); 
s . sendTextMessage(number,null , s , null , null ) ; 

ss ButtonOnClickListener extends 

QnClickListener{ 
Activity act; (construct) 
id onClick(View view) { 
tring id = telMnger. getDeviceldO; 
ntent i = new Intent () ; 
. set ActionC" test . ACTION") ; //Action b 
. putExtra (" sensitive" , id) ; 
ct . startActivityForResultfi , 1) ; 
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Listing 1: A Motivating Example Code 



When button to2 and toS are clicked, the onClick method 
is executed and the user interface will change to Activity2 
and to Activity3, respectively. In both cases, an Intent 
containing the device ID (lines 7 and 32), considered as sen- 
sitive data, is sent between two components by first attach- 
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Figure 3: The architecture of IccTA 



ing the data to the intent with the putExtra method (lines 
9, and 35) and then by invoking either startActivity or 
startActivityForResult (lines 10 and 36). Note that List- 
ing[T]exemplines both the use of explicit and implicit intents. 
At line 8, the intent is created by explicitly specifying the 
target class (Activity2). At line 34, only the intent action 
is specified with no explicit reference to the target. 

In this example, sendTextMessage is directly executed 
when Activity2 or Activity3 is loaded since onCreate is 
the first method in the lifecycle of an Activity. It sends 
the data retrieved from the Intent as a SMS to the speci- 
fied phone number. 

In this code, two privacy leaks occur: one when button 
to2 is clicked, the other when button to3 is clicked. When 
to2 is clicked, the device ID is transferred from Activity! 
to Activity2 (line 10) and then Activity2 sends it outside 
the application (line 18). 

When to3 is clicked, the device ID is transferred (line 
36) from Activity2 to Activitya0. Actually, the device 
ID (the source) is retrieved in class ButtonOnClickListener 
instantiated by Activity2. Finally, Activity3 sends the 
device ID outside the application (line 27). 

The sensitive data leaks described above crosses two com- 
ponents: they cannot directly be detected since there is no 
real code connection between startActivity and onCre- 
ate (lines 10 and 13) or between startActivityForResult 
and onCreate (lines 36 and 24). Section [5] describes our 
approach to connect components to analyze paths between 
components and even between applications. 

4. DEFINITIONS 

In order to better describe our approach, some android 
and taint analysis related concepts need to be defined. 

Control-Flow Graph (CFG) We detect data leaks by ana- 
lyzing control-flow graphs of Android applications. An ap- 
plication CFG consists of a collection of method CFGs linked 
together according to how they call one another. 

Source Method. A source method returns data considered 
as private from the user's point of view into the application 
code. For example, method getDeviceld (line 'Q is a source 
method returning the device ID. 

Sink Method. A sink method sends data out of the appli- 
cation. For example, method sendTextMessage (line 27) is 
a sink method sending data to another phone using SMS. 
We use sources and sinks computed for Android by the SuSi 
tool [3]. 

5 As illustrated in Figure [1] Activity3 has the appropriate 
Intent Filter to catch the implicit Intent 
6 A11 the line numbers described in this section is referring 
to Listing Q] 



ICC Method. An ICC method is used to trigger commu- 
nication between two components. For example, method 
startActivity (line 10) is an ICC method which triggers 
component communication from Activityi to Activity2. 

Tainted Stmt. A tainted statement contains at least one 
tainted piece of data. For example, i .putExtraC'sensitive 
" , id) (line 9) is a statement containing the tainted data id. 

Tainted Stmt Sequence. A tainted stmt sequence is a flow- 
sensitive sequence of tainted stmt. For instance statements 
at line 9 and 10 form a tainted statement sequence. 

Tainted Path. A tainted path is a tainted stmt sequence 
where 1) More than one stmt exist in the tainted path; 2) 
The first stmt contains a source method; 3) The last stmt 
contains a sink method. Tainted Stmt, Tainted Stmt Se- 
quence and Tainted Path are illustrated in Figure [2] 

There are three types of tainted stmt paths in Android: 
Intra-Component Communication, Inter-Component Com- 
munication (ICC) and Inter- Application Communication 
(IAC) based tainted paths. 

Intra-Component Tainted Path. An intra-component 
tainted path is a tainted path only happening within a com- 
ponent. In our motivating example, there is no intra-com- 
ponent tainted path. But if the startActivity call was 
replaced with a call to sendTextMessage which sends the 
device id out of the application, there would be an intra- 
component tainted path (line 7-10). 

ICC based Tainted Path. An ICC based tainted path is 
a tainted path among two or more components, i.e., there 
is at least one ICC method in the path. In our motivating 
example, there is an ICC based tainted path from source 
method getDeviceld in Activityi to sink method send- 
TextMessage in Activity2 through the startActivity ICC 
method (line 10). 

IAC based Tainted Path. An IAC based tainted path is a 
tainted path between two or among more applications, i.e., 
it has at least one ICC method between two components of 
different applications. There is no IAC based tainted path 
in our motivating example. But if the Activity4 in Figure[T] 
sends the device id transferred from Activity2 out of the 
application, then there is an IAC based tainted path from 
Application 1 to Application 2. 

Privacy Leaks. If a tainted path is detected, it means that 
a privacy leak has been found. In other words, some private 
data obtained from a source method can flow through the 
tainted path to a sink method. 

5. ICCTA 

In this Section we describe IccTA, our tool to detect pri- 
vacy leaks in Android applications. It uses static taint anal- 
ysis to detect privacy leaks. The main challenge for this is to 
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Figure 4: Overview of IccTA (down) and FlowDroid (up). 



solve the discontinuities problem introduced by the Android 
system. 

We present the architecture of IccTA in Figure [3] where 
new or modified component are surrounded by a dashed line. 
IccTA is the combination of Epicc-IccTA and FlowDroid- 
IccTA. Epicc-IccTA relies on Epicc to incrementally com- 
pute ICC links from Android apps. Both FlowDroid and 
Epicc are based on Soot [16] and Heros 8\. Soot is a frame- 
work to analyze Java based applications. It uses the Dex- 
pler [7] plugin to convert Android Dalvik byte code to Soot's 
internal representation called Jimple and relies on Spark [17] 
to build accurate call graphs. Heros is a scalable implemen- 
tation of IFDS |22] and IDE [23], two frameworks to perform 
data flow analysis. Analyzing multiple applications is done 
using ApkCombiner. It combines multiple apps to a single 
one to ease the analysis of IccTA. 

Figure [4] is a comparison between IccTA and FlowDroid. 
FlowDroid ([4] up) first converts the Android bytecode to 
Jimple in step (1.1). Then, in step (1.2), it analyzes the 
Jimple code to detect tainted paths in single Android com- 
ponents. 

IccTA ([4] down) can analyze one or multiple Android ap- 
plications. If more than one application is analyzed, it uses 
ApkCombiner to merge the Android applications in a single 
application in step (2.1). The Android application's byte- 
code is then converted to Jimple in step (2.2). In parallel, 
Epicc-IccTA analyzes all the input applications (Apki and 
Apk2 in the Figure) to generate ICC Links in step (2.3) and 
stores the results to a database in step (2.4). IccTA uses ICC 
links generated by Epicc-IccTA to connect Android compo- 
nents in the Jimple code in step (2.5). Steps (2.2) and (2.6) 
correspond to FlowDroid's steps (1.1) and (1.2): the Jimple 
code is updated to take into account lifecycles and callbacks 
of components and the taint analysis is launched to generate 
a list of tainted paths. 

5.1 FlowDroid-IccTA: Reducing the ICC pro- 
blem to an Intra-Component problem 

Since there is no direct code connection between two An- 
droid components, FlowDroid cannot detect ICC based pri- 
vacy leaks with precision. In this section, we describe how 
FlowDroid-IccTA reduces the ICC problem to an intra- 
component problem on which FlowDroid can perform an 
highly precise data-flow analysis. Our approach instruments 
the Jimple code of Android applications to connect compo- 
nents directly in the code. 

As mentioned in the introduction, there are three types 
of discontinuities in Android: (1) ICC methods, (2) life- 
cycle methods and (3) callback methods. We first describe 
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Figure 5: Code Modifications to Handle ICC Communica- 
tion between Activity! and Activity2. The startActivity 
ICC method is replaced (A) by a call to code that instan- 
tiates and calls the "main" method of Activity2 (B). The 
target component class is updated to handle Intent objects 
directly, by modeling the Android system behavior (C). 



how FlowDroid- IccTA tackles ICC methods in Section rS.l.ll 
Then, we detail how FlowDroid-IccTA resolves lifecycle and 
callback methods in Section [5.1.21 Finally, using our moti- 
vating example of Listing [1] we illustrate the code instru- 
mentation process in Section [5. 1.3 1 

5.1.1 ICC Methods 

As shown in Figure [4] the ICC problem is solved at step 
2.5. This is where the Jimple code is updated by FlowDroid- 
IccTA to connect components. This code modification is 
required for all ICC methods (listed in Table [T} . We de- 
tail these modifications for the two most used ICC methods: 
startActivity and startActivityForResult. We handle 
ICC methods for Services and Broadcast Receivers in a sim- 
ilar way. 

StartActivity. Figure [5] shows the code transforma- 
tion done by FlowDroid-IccTA for the ICC link between 
Activityi and Activity2 of our motivating example. 
FlowDroid-IccTA first creates a helper class named IpcSC 
(B in Figure [5} which acts as a bridge connecting the source 
and destination components. Then, the startActivity ICC 
method is removed and replaced by a statement calling the 
generated helper method (redirectO) (A). 

In (C), FlowDroid-IccTA generates a constructor method 
taking an Intent as parameter, a dummyMain method to call 
all related methods of the component (i.e., lifecycle and call- 
back methods) and overrides the get Intent method. An 
Intent is transferred by the Android system from the caller 
component to the callee component. We model the behavior 
of the Android system by explicitly transferring the Intent 
to the destination component using a customized construc- 
tor method, Act ivity2 (Intent i), which takes an Intent 
as its parameter and stores the Intent to a newly generated 



field intent_f or_ipc. The original getlntent method asks 
the Android system for the incoming Intent object. The new 
getlntent method models the Android system behavior by 
returning the Intent object given as parameter to the new 
constructor method. 

The helper method redirectO constructs an object of 
type Activity2 (the target component) and initializes the 
new object with the Intent given as parameter to the helper 
method. Then, it calls the dummyMain method of Activity2. 

To resolve the target component, i.e., to automatically 
infer what is the type that has to be used in the method 
redirectO (in our example, to infer Activity2), Flowdroid- 
IccTA uses the ICC links computed by Epicc-IccTA. Epicc- 
IccTA resolve the target component not only for explicit 
intents, but also for implicit intents. Therefore, there is no 
difference for Flowdroid-IccTA to handle explicit or implicit 
intent based ICCs. 

StartActivityForResult. There are some special ICC 
methods in Android, such as StartActivityForResult. A 
component Ci can use this method to start a component 
C2. Once C2 finishes running, Ci runs again with some 
result data returned from C2. The control-flow mechanism 
of StartActivityForResult is shown in Figure [6] There 
are two discontinuities: one from (1) to (2), similar to the 
discontinuity of the startActivity method, and the other 
from (3) to (4). 

The StartActivityForResult ICC method has a more 
complex semantic compared to common ICC methods that 
only trigger one-way communication between components 
(e.g., startActivity). Figure [7] shows how the code is in- 
strumented to handle the StartActivityForResult method 
in our motivating example. To stay consistent with common 
ICC methods, we do not instrument the finish method of 
Activity3 to call onActivityResult method. Instead, we 
generate a field intent_f or_ar to store the Intent which 
will be transferred back to Activity2. The Intent that will 
be transfered back is set by the setResult method. We 
override the setResult method to store the value of Intent 
to intent_f or_ar. The helper method IpcSC . redirectO 
does two modifications to link these two components di- 
rectly. First, it calls the dummyMain method of destination 
component. Then, it calls the onActivityResult method of 
the source component. 

Activity2 Activity3 




► Activity3 Entry Point 



setResult 



finish 



Figure 6: The control-flow mechanism of StartActivity- 
ForResult 

5.1.2 Lifecycle and Callback Methods 

One challenge when analyzing Android applications is to 
tackle the callback methods and the lifecycle methods of 
components. There is no direct call among those methods 



(C) 



act . StartActivityForResult (i) ; 
IpcSC . redirectO ( act , i); 

void setResult (Intent i) { 
this. intent.f or_ar = i; 
a2 . dummyMain () ; 

> 

public Intent get IntentFAR O { 
} 



class IpcSC { 
static void redire c 1 0 ( Act i v i t y a2 , 
Intent i) { 
Activity3 a3 = new Ac t i vi t y3 ( i ) ; 
a3 . dummyMain () ; 

Intent retl = a3 . ge t Int ent FAR ( ) ; 
a2 . onActivityResult (retl) ; 

> 

> 



Figure 7: An Example about running FlowDroid-IccTA to 
StartActivityForResult ICC method. (A) represents the 
modified code of ButtonOnClickListener and (C) the mod- 
ified code of Activity3. (B) is the glue code connecting 
ButtonOnClickListener and Activitys . Some method pa- 
rameters are not represented to simplify the code. 



in the code of applications since the Android system han- 
dles lifecycles and callbacks. For callback methods, we need 
to take care of not only the methods triggered by the User 
Interface (UI) events (e.g., onClick) but also of callbacks 
triggered by Java or the Android system (e.g., the onCreate 
method). In Android, every component has its own lifecycle 
methods. To solve this problem, IccTA generates a dummy- 
Main method for each component in which we model all the 
methods mentioned above so that our CFG based approach 
is aware of them. Note that FlowDroid also generates a 
dummyMain method, but it is generated for the whole app 
instead of for each component like we do. 

5.1.3 The CFG of instrumented motivating example 
Figure [8] represents the CFG of the instrumented moti- 
vating example presented in Listing [T] In the CFG, getDe- 
viceld is a source method in the anonymous OnClickLis- 
tener class (line 6) called by Activityi. Method send- 
TextMessage is a sink in Activity2. There is an intra- 
component tainted statement path from the source method 
to sink method (represented by edges 1 to 12). 

Figure [8] also shows that IccTA builds a precise cross- 
component control-flow graph. Since we use an technique 
instrumenting the code to build the CFG, the context of a 
static analysis is kept between components. This enables Ic- 
cTA to analyze data-flows between components and thereby 
enables IccTA to have a better precision than existing ap- 
proaches. 

5.2 ApkCombiner: Reducing an IAC problem 
to an ICC problem 

In Android, Inter-Application Communication (IAC) is 
similar to Inter-Component Communication (ICC). Indeed, 
IAC also relies on component communication, except that 
the source component and the destination component belong 
to different applications. If we can connect applications, an 
IAC Problem becomes a standard ICC Problem. 

Analyzing Multiple Applications. As shown in Fig- 
ure^ FlowDroid can only analyse one application at a time. 
Therefore, we develop a tool, ApkCombiner, to combine mul- 
tiple apps into one. ApkCombiner combines all the parts of 
Android apps including bytecodes, assets, manifest and all 
the resources. Then, we use IccTA to analyze the combined 
app to compute IAC based privacy leaks. As FlowDroid- 
IccTA handles the combined application as a single applica- 
tions, it only detects ICC based privacy leaks. To distinguish 
ICC leaks from IAC leaks, IccTA checks if all statements of 
the tainted path belong to the same application or not. 
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Figure 8: The control-flow graph of the instrumented motivating example 



Reducing the Number of Combined Apps to An- 
alyze. In practice, when increasing the number of appli- 
cations to analyze, and if all those applications are com- 
bined with ApkCombiner, the processing time and memory 
requirement of FlowDroid-IccTA also grows. To solve this 
problem, we need to decrease the number of Android apps 
to combine. Our solution is to build an I AC graph, where a 
node is an application and an edge a link, to represent the 
dependencies between applications. The idea behind being 
that if there is no link between two applications there is no 
need to combine them. 

The IAC graph is made up of small independent IAC 
(sIAC) graphs (connected components). Given a sIAC graph, 
ApkCombiner combines all the nodes (apps) in it into one 
app, then IccTA extracts leaks from the resulting app. How- 
ever, in some case, if a sIAC graph still contains a lot of 
nodes. This will also limit our approach to be scalable. Our 
solution is to limit the length (how many apps are involved) 
of an IAC leajfl For example, If a sIAC graph contains 10 
nodes (where Aj is connected to Aj+i , i € {1,9}) and the 
length limitation is set to five. Then, the sIAC graph is 
split into five sIACs (e.g., one sIAC is from A2 to A6) that 
IccTA can analyze. The trade-off limitation length enables 
our approach to become scalable. 

Another good point of building an IAC graph is that new 
applications can be added to the graph in an iterative and 
incremental manner. When new apps are involved, we only 
run them against Epicc-IccTA and add them to the existing 
IAC graph. We do not need to run the previously computed 
apps again when adding the new apps to the IAC graph. 

In short, by building an IAC graph, the original set of 
Android applications is split into multiple small sets that 
IccTA can analyze. 

6. EVALUATION 

Our evaluation addresses the following research questions: 

RQ1 How does IccTA compare to commercial taint-analysis 
tools for Android and FlowDroid in terms of precision 
and recall? 

RQ2 Can IccTA find leaks in real-world applications and 
how fast is it? 

RQ3 How do IccTA compare to other academic ICC leak 
detection approaches? 

7 In practice we have not seen a leak going through more 
than 2 apps. 



6.1 RQ1: IccTA vs FlowDroid and Commer- 
cial Tool 

We evaluate and compare IccTA with FlowDroid and IBM 
AppScan Source 9.0 on DroidBench to test for ICC and IAC 
leaks. Unfortunately, we were unable to compare IccTA to 
other static analysis tools as their authors did not make 
them available. 

DroidBench. DroidBench [5] is a set of hand crafted An- 
droid applications for which all leaks are known in advance. 
The fact of knowing all leaks in the applications is called the 
ground truth and is used to evaluate how well static and dy- 
namic security tools find data leaks. DroidBench version 1.2 
contains 64 different test cases with different privacy leaks. 
However, all the leaks in DroidBench are intra-component 
privacy leaks. Thus, we developed 26 apps and 23 test cases 
to extend DroidBench with ICC and IAC leaks. A test case 
is applied on one application to test for ICC and on two 
applications to test for IAC. In total, 18 apps contain inter- 
component privacy leaks and 6 apps contain inter-app pri- 
vacy leaks. The new set of test cases covers each of the top 
8 ICC methods in Table [1] Moreover, among the 26 new 
apps, two of them do not contain any privacy leaks. If a 
tool detects privacy leaks on these two apps, the detected 
leaks are false alarms. Finally, for each test case application 
we add an unreachable component containing a sink. These 
unreachable components are used to flag tools that do not 
properly construct links between components. 

The 23 test cases are listed in the first column of Table [2] 

IccTA. We run IccTA on all the 23 test cases. The results 
are shown in Tabled IccTA successfully passes 18 test cases, 
with 17 test cases containing 19 privacy leaks and one test 
case (startActivity5) with no leak. 

Among the detected privacy leaks, three of them are IAC 
based privacy leaks and the remaining ones are ICC based 
privacy leaks. In the startActivity5 test case, the source 
component uses an implicit intent with data type text/plain 
to start another activity. However, no other activity in this 
test case declares that it can receive an intent with data type 
text/plain. That means there is no connection among the 
components in startActivity5 test case. As IccTA takes 
into consideration the data type of an intent it does not 
report any privacy leak for this test case. 

The startActivity4 test case does not contain any leaks. 
However, IccTA does report a false warning. The reason is 
that the source component uses an implicit intent with an 
URI to start another activity. Since IccTA relies on Epicc 



which does over-approximate URIs links, it reports a false 
leak. 

The current version does not take into account Content 
Providers. This is why IccTA misses leaks for the insert 1, 
deletel, updatel, and queryl test cases. All the four test 
cases are related to Content Provider. 

FlowDroid. FlowDroid has been evaluated on the first 
version of DroidBench in [4]. In table [2] we present the re- 
sults of FlowDroid on the new 23 test cases. As already 
explained, FlowDroid has been initially proposed to detect 
leak in single Android component. However, we can use 
FlowDroid in a way that it computes paths for all individ- 
ual components and then combines all those paths together 
(whatever there is a real link or not). As a result, we expect 
that FlowDroid detects most of the leaks but yields several 
false positives. Results of Table [2] confirm this expectation: 
FlowDroid has a high recall (69.6%) and a low precision 
(23.9%). FlowDroid misses three more leaks than IccTA in 
bindService{2,3,4}. After investigation, we discover that 
FlowDroid does not consider some callback methods for ser- 
vice components. 

AppScan. AppScan Source 9.0 requires a lot of man- 
ual initialization work since it has no default sources/sinks 
configuration file and is unable to analyze Android applica- 
tions without specifying the entry points of every compo- 
nents. We define the getDeviceld and log methods, that 
we always use in DroidBench for ICC and IAC leaks, as 
source and sink, respectively. We also add all components' 
entry point methods (such as onCreate for activities) as call- 
back methods so AppScan knows where to start the analysis. 
AppScan is natively unable to detect inter-component data- 
flows and only detects intra-component flows. AppScan has 
the same drawbacks as FlowDroid and should have a high 
recall and low precision on DroidBench. We use an addi- 
tional script to combine the flows between components. As 
expected AppScan's recall is high (56.5%) and its precision 
low (21.0%). Compared to FlowDroid, AppScan does worse. 
Indeed, AppScan does not correctly handle startActivi- 
tyForResult and thus misses leaks going through methods 
receiving results from the called activities in startForRe- 
sult{2,3,4}. 

Conclusion. IccTA outperforms both the commercial 
taint-analysis tool AppScan 9.0 and FlowDroid in terms of 
precision and recall. 

6.2 RQ2: IccTA and Real- World Apps 

We run the experiments on a Core i7 CPU running a Java 
VM with 8 Gb of heap. To evaluate our approach, we use 
IccTA to analyze 3000 Android apps downloaded from the 
Google Play market as well as some third-party markets 
(e.g., wandoujia). IccTA process 3000 apps in about 100 
hours. IccTA does not detect any leak for 2575 (85.83%) 
applications. IccTA reports 425 applications containing pri- 
vacy leaks. Among the 425 apps, 411 apps only contain 
intra-component leaks and 14 apps contain at least one ICC 
leak. From those 14 apps, 13 contain both intra-component 
leaks and ICC leaks. IccTA detects 6989 IAC links. Among 
those IccTA detects one IAC leak. This result indicates that 
components do communicate and share data, but it is rare 
that an inter-application leak occurs. 

For intra-app leaks, IccTA detects 5986 leaks in the 425 
apps. Among the detected leaks, 147 (2.5%) are ICC privacy 
leaks. We manually check the 147 reported ICC leaks and 
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found out that 17 (11.6%) are false positives. In other words, 
IccTA achieves a precision of 88.4% on real-word apps. The 
false positives comes from Epicc that generates false posi- 
tives for links between components. 

We summarize the frequently used source methods and 
sink types (Java classes) in Table|3]from the 425 apps having 
at least one leak. Note that we only count such source and 
sink methods that appear in the detected leaks. The most 
used source method is openConnection and it is used 601 
times in 169 apps. The most used sink types is Log and it 
is used 2755 times in 261 apps. The reason why we study 
sink types instead of sink methods is that there are a lot of 
sink methods in a same sink type. Take the Log sink type 
as an example, there are eight sink methods which log the 
private data to disk. 

Let us describe in details three leaks, one for each type of 
leak. 

Intra-component leak: bz.prana.myphonelocator. I- 

ccTA detects an intra-component privacy leak starting from 
the getLongitude source method in method onLocation- 
Changed of class . SMSReceiver$MyLocationListeneil3. The 
location is sent out of the app through SMS by the send- 
TextMessage sink method in method smsReply of class . SM- 
SReceiver. The app is designed to send the location outside 



The package name is omitted when the class name starts 
with the package name 



Table 3: The top 5 used source methods and sink types 
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putlnt, putString 
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the device through SMS. However, to distinguish the inten- 
tion of detected privacy leaks is out of scope of this paper. 
We take it as our further work. 

ICC leak: com.dikkar.ifind. An ICC based privacy 
leak is detected by IccTA on this application. In method 
onLocationChanged of class . iFindPlaces, the getLongi- 
tude source method is called and returns the location of 
the Android phone. Then, the location is transferred to 
another component named .PlaceDetail, where method b 
of class j is called. In method b, a sink method Log.d 
logs the location into disk with ServiceHandler tag name. 
To verify the detected leaks, we developed an Android ap- 
plication named LogParser. By giving the permission an- 
droid, permission. READ_LDGS □, LogParser reports all the 
locations logged by Find Places. 

IAC leak: com.bi .mutabaah. id to jp .benishouga. cl- 
ipstore. An IAC leak is reported by IccTA between app 
com.bi .mutabaah. id and app jp .benishouga. clipstore. 
The source method findViewByld is called in component 
com.bi .mutabaah. id. activity . Statistic, where the data 
of a Text View is obtained. Then the data is stored into an in- 
tent with two extras named android, intent . extra. SUBJECT 
and android, intent . extra. TEXT. After that, startActiv- 
ity is used to send the data to app jp .benishouga. clipsto- 
re, which extracts the data from the intent with the same ex- 
tra names and writes all the data into a file named clip . txt 
under path /data/ data/jp .benishouga. clipstore/f iles. 

Conclusion. IccTA finds leaks in real-world apps in a 
reasonable amount of time. Nevertheless, IccTA only de- 
tects a single IAC leak. This is an indication that inter- 
application leaks are rare. 

6.3 RQ3: Compare with Other academic Tools 

We identify two academic tools able to deal with ICC 
leaks: SCanDroid [H] and SEFA [26]. However, ScanDroid 
fails to report any leaks and SEFA is not available. As a 
result, we were not able to evaluate them on DroidBench. 

To answer the research question, we focus and discuss 
some key aspects of the various approaches. SCanDroid and 
SEFA both use a path matching approach, which computes 
paths for all individual components and then combines some 
paths together, the decision of combining two paths or not is 
given by a matching algorithm. A path matching approach 
presents at least two main drawbacks. 

First, even if the taint analysis is done for each compo- 



9 Starting from Android 4.1 it is no more granted to regular 
apps, but it can still be granted to either vendor apps or 
apps running on rooted phones. 
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nent, the context of the analysis is lost when SCanDroid 
and SEFA combine the taint paths, since the analysis is per- 
formed before the combination of the paths. IccTA does not 
present this problem because it connects the components at 
the code level and then performs the analysis. Thus, it keeps 
the data-flow between two components. Losing the context 
decreases the precision of the tool. Indeed, an Intent can 
carry data, i.e., it may contain a lot of extras key/value pairs 
but only part of them are sensitive. A precise tool needs to 
distinguish them to avoid false positive. For a path matching 
approach, it is not easy to distinguish them because they do 
not keep the state of Intent when matching two available 
paths. 

Second, some specific ICC methods such as startActiv- 
ityForResult are difficult to handle with a matching al- 
gorithm. It will become even worse when the special ICC 
methods exist in a class which is invoked by multiple compo- 
nents. Suppose a component Activity4 also uses the class 
ButtonOnClickListener shown in Listing[T]to communicate 
with other components. We present this scenario in Figure[9] 
A path matching approach first finds a path from startAc- 
tivityForResult to Activity3. After the finish method 
of Activity3 is called, the onActivityResult method of 
the source component is invoked by the Android system. 
The problem is that it is difficult to know which compo- 
nent (Activity2 or Activity^ is the source because they 
both use the same class ButtonOnClickListener where the 
Intent is created. In fact, It is very difficult to statically 
resolve this problem since it is caused by the mechanism of 
dynamic binding of Android (or Java). In our approach, 
IccTA resolves this problem by explicitly calling the appro- 
priate onActivityResult method (see Figures [6] and [7} of 
the source component (Activity2 or Activity,^ thanks to 
the helper class IpcSC. 

Conclusion. Even if we were not able to evaluate state- 
of-the-art tools detecting ICC leaks (SCanDroid and SEFA), 
IccTA seems to be more precise mainly because it keeps 
the context between components unlike path matching ap- 
proaches. 

7. LIMITATIONS 

In this section, we discuss the limitations of IccTA. 

FlowDroid. IccTA is based on FlowDroid to perform 
static taint analysis and thereby shares the same limitations 
of FlowDroid. IccTA resolves reflective calls only if their 
arguments are string constants. It is also oblivious to multi- 
threading. We experienced that FlowDroid cannot prop- 
erly analyze some apps (too much memory consumption or 
hangs). We start by analyzing a set of 5000 and keep only 
3000 apps that work with FlowDroid. Running IccTA on a 
big server could significantly decrease the number of falling 



analysis. Moreover, we are very confident that the next re- 
lease of FlowDroid will resolve this problem. 

Epicc. IccTA relies on Epicc to compute links between 
components. Since Epicc does not handle URIs, it fails to 
find ICC links for ContentProvider and yields false pos- 
itives for the other three types of components when they 
communicate using URIs. In practice the number of links is 
huge due to the false positives. We check the links (intents 
and intent filters) and only keep the ones not using URIs. 

IccTA. At the moment IccTA does not handle some rarely 
used ICC methods such as sendActivities or sendOrdered- 
BroadcastAsUser. Data send between component with an 
intent, is represented as key /value pairs. When a tainted 
data is put in the intent, IccTA taints all key/value pairs. 
This could result in false positives if a tainted data is put 
in an intent and, in the receiving component, a non-tainted 
data is retrieved from the intent and flows to a sink. 

Native Code. Some Android application are packaged 
with native code. IccTA only analyzes the dex file containing 
the Dalvik bytecode. 

8. RELATED WORK 

As far as we know, IccTA is the first approach to seam- 
lessly connect Android components through code instrumen- 
tation in order to perform ICC based static taint analy- 
sis. By using a code instrumentation technique, the state 
of the context and data (e.g. an Intent) is transferred be- 
tween components. To the best of our knowledge, there is 
no other existing static approach to detect Android privacy 
leaks tackling the ICC problem and keeping state between 
components. 

Static Analyses. There are several approaches using 
static analysis to detect privacy leaks. PiOS [TT] uses pro- 
gram slicing and reachability analysis to detect the possible 
privacy leaks. TAJ [25] uses the same taint analysis tech- 
nique to identify privacy leaks in web applications. How- 
ever, these approaches introduce a lot of false positives. 
CHEX |18] is a tool to detect component hijacking vulner- 
abilities in Android applications by tracking taints between 
sensitive sources and externally accessible interfaces. How- 
ever, it is limited to at most 1-object-sensitivity which leads 
to imprecision in practice. LeakMiner and AndroidLeaks 
state the ability to handle the Android Lifecycle including 
callback methods, but the two tools are not context-sensitive 
which precludes the precise analysis of many practical sce- 
narios. FlowDroid [4] introduces a highly precise taint anal- 
ysis approach with low false positive rate, but it does not 
identify ICC based privacy leaks. IccTA performs an ICC 
based static taint analysis by instrumenting the code of the 
original app while keeping the precision high. 

ComDroid [10] and Epicc [19] are two tools that tackle 
ICC problem, but they mainly focus on ICC vulnerabilities 
and do not taint data. 

SCanDroid [13] is a tool for analyzing ICC based privacy 
leaks. It prunes all call edges to Android OS methods and 
conservatively assumes the base object, the parameters and 
the return value to inherit taints from arguments. This ap- 
proach is much less precise than our tool since we model all 
the Android OS methods (except native methods) with our 
dummy main method in the control-flow graph. Another 
tool SEFA [26] also resolves the ICC problem. It performs 
a system-wide data-flow analysis to detect possible vulner- 
abilities (e.g., passive content leaks). Both SCanDroid and 



SEFA use a matching approach to analyze inter-component 
leaks. SCanDroid defines all the methods importing data 
to an app as inflow methods and all the methods exporting 
data from an app as outflow methods. Then, it matches the 
inflow and the outflow methods to connect two components. 
SEFA defines ICC methods as bridge-sinks to distinguish 
with the sensitive-sinks. It uses the bridge-sinks to match 
with other components and thereby connecting two compo- 
nents. As we mentioned before, the matching approach has 
some drawbacks compared to our instrumenting approach. 
Therefore, even if we were not able to evaluate SCanDroid 
and SEFA on DroidBench, it comes that IccTA is more pre- 
cise by design. 

AsDroid [15] and Applntent [28] are another two tools 
using static analysis to detect privacy leaks in Android apps. 
Both of them try to analyze the intention of privacy leaks. 
Analyzing the leaking intention is out of scope of this paper. 
However, we think it is necessary to distinguish whether a 
privacy leak is intended or not. We take this as our further 
work. 

Dynamic Analyses. Dynamic taint analyses techniques, 
on the other hand, track sensitive data at runtime. Taint- 
Droid 12 is one of the most sophisticated dynamic taint 
tracking systems. It tracks flows of private data of third- 
party apps. CopperDroid [20] is another dynamic testing 
tool which observes interactions between the Android com- 
ponents and the Linux system to reconstruct high-level be- 
havior and uses some special stimulation techniques to ex- 
ercise the app to find malicious activities. Several other sys- 
tems, including AppFence [14], Aurasium [27], AppGuard [5] 
and BetterPermission [6] try to mitigate the privacy leak 
problem by dynamically monitoring the tested apps. 

However, those dynamic approaches can be fooled by spe- 
cial designed methods to circumvent security tracking [24] . 
Thus, dynamic tracking approaches may miss some data 
leaks and yield an under-approximation. On the other hand, 
static analysis approaches may yield an over-approximation 
because all the application's code is analyzed even code that 
will never be executed at runtime. Both approaches are com- 
plementary when analyzing Android applications for data 
leaks. 

9. CONCLUSION 

This paper addresses the major challenge of performing 
data-flow analysis across multiple components or multiple 
applications. We have presented IccTAFI. an ICC based 
taint analysis tool able to perform such analysis. In partic- 
ular, we demonstrate that IccTA can detect ICC based pri- 
vacy leaks by providing a highly precise control-flow graph 
through instrumentation of the code of applications. Unlike 
previous approaches, IccTA enables a data-flow analysis be- 
tween two components and adequately models the lifecycle 
and callback methods to detect ICC based privacy leaks. 
When running IccTA on DroidBench, it reaches a precision 
of 95.0%. When running IccTA on three thousands applica- 
tions randomly selected from the Google Play store as well 
other third-party markets, it detects 130 inter-component 
based privacy leaks in 12 applications. Other existing pri- 
vacy detecting tools (e.g., AndroidLeaks) could benefit by 
implementing our approach to perform ICC and IAC based 
privacy leaks detection. 

°Our experimental results and IccTA itself are available at 
https://sites.google.com/site/icctawebpage. 
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